home *** CD-ROM | disk | FTP | other *** search
/ Amiga Developer CD 2.1 / Amiga Developer CD v2.1.iso / Extras / IFF / IFF_Forms / ANIM.op8.doc < prev    next >
Encoding:
Text File  |  1993-03-01  |  7.0 KB  |  147 lines
  1.  
  2. -------------------------------------------------------------------------
  3. Appendix for Anim8 Formats               Joe Porkka 10-jan-92
  4. -------------------------------------------------------------------------
  5.  
  6.  
  7.  
  8.    Anim method 8 is designed for maximum playback speed and acceptable
  9.    packing rates (packing usually not as good as method 5, but more
  10.    efficient than methodes 1 -- 4). In addition, it is easier to convert
  11.    existing Anim5 code to support Anim8 than Anim7.
  12.  
  13.    #.# Chunk Sequence:
  14.  
  15.    Method 8 Anims should use the same Chunk Sequence as methods 1..5.
  16.    Alternativley the first frame may have a DLTA chunk instead
  17.    of the BODY chunk.
  18.    In that case the DLTA is the difference to a 'black frame'.
  19.    A player has to clear all bitplanes of the first bitmap to zero,
  20.    and then call his DLTA unpack routines for this frame.
  21.    The same rules about copying the first frame into both frame
  22.    buffers still applies in this case.
  23.  
  24.                       FORM ANIM
  25.                       . FORM ILBM         first frame
  26.                       . . BMHD                normal type IFF data
  27.                       . . ANHD                optional animation header
  28.                                               chunk for timing of 1st frame.
  29.                       . . CMAP
  30.                       . . { BODY |            full picture or
  31.                             DLTA }            difference to 'black frame'
  32.                       . FORM ILBM         frame 2
  33.                       . . ANHD                animation header chunk
  34.                       . . DLTA                delta mode data
  35.                       . . [CMAP]
  36.                       . FORM ILBM         frame 3
  37.                       . . ANHD
  38.                       . . DLTA
  39.                       . . [CMAP]
  40.                            ...
  41.  
  42.       The initial FORM ILBM can contain all the normal ILBM chunks,
  43.       such as CRNG, etc.  The BODY will normally be a standard
  44.       run-length-encoded data chunk (but may be any other legal
  45.       compression mode as indicated by the BMHD).  If desired, an ANHD
  46.       chunk can appear here to provide timing data for the first
  47.       frame.  If it is here, the operation field should be =0.
  48.  
  49.       If the initial FORM ILBM uses a DLTA chunk, the ANHD chunk
  50.       must appear, and the operation field must be set to the
  51.       according anim method.
  52.  
  53.       Each of the frames from frame 2 on up may use an anhd->operation
  54.       of 0, 5 or 8. Note that only for the first frame in the file do
  55.       you copy the image data into two buffers, not every time you get
  56.       an ANHD->operation==0.
  57.  
  58.    # Chunk Formats
  59.    #.# ANHD Chunk for method 8
  60.       The ANHD chunk consists of the following data structure:
  61.  
  62.            UBYTE operation  The compression method:
  63.                             =8 short/long Vertical Delta mode
  64.  
  65.            UBYTE mask         unused
  66.            UWORD w,h          unused
  67.            WORD  x,y          unused
  68.            ULONG abstime      unused
  69.            ULONG reltime     (timing for frame relative to time
  70.                               previous frame was displayed - in
  71.                               jiffies (1/60 sec))
  72.            UBYTE interleave = 0 (see ANHD description above)
  73.            UBYTE pad0         unused
  74.            ULONG bits         32 option bits used by methode=4 and 5.
  75.                               methode 8 uses only bit #0
  76.  
  77.                              bit #              set =0               set =1
  78.                              ===============================================
  79.                              0              short data           long data
  80.  
  81.            UBYTE pad[16]       unused
  82.  
  83.  
  84.    #.# DLTA Chunk
  85.       #.#.# Format for method 8
  86.  
  87.          The DLTA Chunks of method8 consists of
  88.  
  89.          - 16 pointers   same as in method 5
  90.  
  91.          In this method the DLTA Chunk begins with 16 pointers.
  92.          The first 8 longwords are pointers to the opcode lists for up to 8
  93.          planes. The  second set of 8 longwords are unused.  If there are
  94.          less than 8 Planes all unused pointers are set to zero.
  95.  
  96.          Compression/decompression is performed on a plane-by-plane basis.
  97.          The following description of the method is similar to
  98.          Jim Kent's methode 5, except that data is either in WORDs or LONGS,
  99.          depending on bit 0 of the ANHD bits.
  100.  
  101.          In methode 8 the bitplane is split into vertical columns.
  102.          Each column of the bitplane is compressed separately.
  103.          A 320x200 bitplane would have 20 columns of 200 short datas each.
  104.          (or 10 columns of 200 long datas)
  105.  
  106.                 Each column of the bitplane is compressed
  107.                 separately.  A 320x200 bitplane would have 20
  108.                 (WORD) or 10 (LONG)columns of 200 bytes each.
  109.                 Each column starts with an op-count followed by a
  110.                 number of ops.  If the op-count is zero, that's
  111.                 ok, it just means there's no change in this
  112.                 column from the last frame.  The ops are of three
  113.                 classes, and followed by a varying amount of data
  114.                 depending on which class:
  115.  
  116.                   1. Skip ops - this is a word or long with the hi bit
  117.                      clear that says how many rows to move the "dest"
  118.                      pointer forward, ie to skip. It is non-zero.
  119.                              Note that the range of values is much larger
  120.                              for word and long data, 0x7fff and 0x7fffffff.
  121.                   2. Uniq ops - this is a word or long with the hi bit set.
  122.                      The hi bit is masked down and the remainder is a count
  123.                      of the number of bytes of data to copy literally. 
  124.                      It's of course followed by the data to copy.
  125.                              Note that the range of values is much larger
  126.                              for word and long data, 0x7fff and 0x7fffffff.
  127.                   3. Same ops - this is a 0 word or long followed by a
  128.                      count word or long,
  129.                      followed by a word or long value to repeat count times.
  130.                              Note that the range of values is much larger
  131.                              for word and long data, 0xffff and 0xffffffff.
  132.  
  133.                 Do bear in mind that the data is compressed vertically rather
  134.                 than horizontally, so to get to the next word or long in the des
  135. tination
  136.                 we add the number of bytes per row instead of one!
  137.  
  138.         There is a slight complication in the case of long data. Normally an
  139.         Amiga BitMap is and even number of 16bit WORDs wide, so it is possible
  140.         to have an image which is not an even number or LONGs wide. For example,
  141.         an image which is 336 pixels wide is 42 bytes wide, 21 words wide, and
  142.         10.5 longs wide. In the case that the data is not an even number of longs
  143.         wide, and the data is to be long compressed, then the last column of
  144.         data is to be word compressed instead. So, that 336 pixel wide image would
  145.         be compress as 10 long columns and 1 word column.
  146.  
  147.